Search for: All records

We describe the target selection and characteristics of the DESI Peculiar Velocity Survey, the largest survey of peculiar velocities (PVs) using both the fundamental plane (FP) and the Tully–Fisher (TF) relationship planned to date. We detail how we identify suitable early-type galaxies (ETGs) for the FP and suitable late-type galaxies (LTGs) for the TF relation using the photometric data provided by the DESI Legacy Imaging Survey DR9. Subsequently, we provide targets for 373 533 ETGs and 118 637 LTGs within the Dark Energy Spectroscopic Instrument (DESI) 5-yr footprint. We validate these photometric selections using existing morphological classifications. Furthermore, we demonstrate using survey validation data that DESI is able to measure the spectroscopic properties to sufficient precision to obtain PVs for our targets. Based on realistic DESI fibre assignment simulations and spectroscopic success rates, we predict the final DESI PV Survey will obtain ∼133 000 FP-based and ∼53 000 TF-based PV measurements over an area of 14 000 deg2. We forecast the ability of using these data to measure the clustering of galaxy positions and PVs from the combined DESI PV and Bright Galaxy Surveys (BGS), which allows for cancellation of cosmic variance at low redshifts. With these forecasts, we anticipate a 4 per cent statistical measurement on the growth rate of structure at z < 0.15. This is over two times better than achievable with redshifts from the BGS alone. The combined DESI PV and BGS will enable the most precise tests to date of the time and scale dependence of large-scale structure growth at z < 0.15.

Current neutrino detectors will observe hundreds to thousands of neutrinos from Galactic supernovae, and future detectors will increase this yield by an order of magnitude or more. With such a data set comes the potential for a huge increase in our understanding of the explosions of massive stars, nuclear physics under extreme conditions, and the properties of the neutrino. However, there is currently a large gap between supernova simulations and the corresponding signals in neutrino detectors, which will make any comparison between theory and observation very difficult. SNEWPY is an open-source software package that bridges this gap. The SNEWPY code can interface with supernova simulation data to generate from the model either a time series of neutrino spectral fluences at Earth, or the total time-integrated spectral fluence. Data from several hundred simulations of core-collapse, thermonuclear, and pair-instability supernovae is included in the package. This output may then be used by an event generator such as sntools or an event rate calculator such as the SuperNova Observatories with General Long Baseline Experiment Simulator (SNOwGLoBES). Additional routines in the SNEWPY package automate the processing of the generated data through the SNOwGLoBES software and collate its output into the observable channels of each detector. In this paper we describe the contents of the package, the physics behind SNEWPY, the organization of the code, and provide examples of how to make use of its capabilities.

Developing sustainable software for the scientific community requires expertise in software engineering and domain science. This can be challenging due to the unique needs of scientific software, the insufficient resources for software engineering practices in the scientific community, and the complexity of developing for evolving scientific contexts. While open‐source software can partially address these concerns, it can introduce complicating dependencies and delay development. These issues can be reduced if scientists and software developers collaborate. We present a case study wherein scientists from the SuperNova Early Warning System collaborated with software developers from the Scalable Cyberinfrastructure for Multi‐Messenger Astrophysics project. The collaboration addressed the difficulties of open‐source software development, but presented additional risks to each team. For the scientists, there was a concern of relying on external systems and lacking control in the development process. For the developers, there was a risk in supporting a user‐group while maintaining core development. These issues were mitigated by creating a second Agile Scrum framework in parallel with the developers' ongoing Agile Scrum process. This Agile collaboration promoted communication, ensured that the scientists had an active role in development, and allowed the developers to evaluate and implement the scientists' software requirements. The collaboration provided benefits for each group: the scientists actuated their development by using an existing platform, and the developers utilized the scientists' use‐case to improve their systems. This case study suggests that scientists and software developers can avoid scientific computing issues by collaborating and that Agile Scrum methods can address emergent concerns.